Do not start SCTP iterator thread when library is initialized via usrsctp_init_nothreads.#472
Conversation
SCTP iterator when initialized via usrsctp_init_nothreads.SCTP iterator when library is initialized via usrsctp_init_nothreads.
SCTP iterator when library is initialized via usrsctp_init_nothreads.SCTP iterator thread when library is initialized via usrsctp_init_nothreads.
|
The problem I see with this approach is that the |
|
Thanks you very much for your time and viewing this PR Dr. @tuexen! Yes, that also my concern. But when I proposed this change I thought of following:
Maybe my understanding of Do you think it is possible to change signature of Thank you very much! |
I was also assuming for some time that you would use the userland stack in the context of WebRTC (with AF_CONN sockets). For native SCTP you would use a kernel stack. But people are using, as far as I can tell from bug reports, it also for native SCTP usage.
The question is: When you are using the library in single threaded mode, are you expecting calls to the library taking an arbitrary long time?
Again, one has to provide a way how the library is expected to be used.
Maybe a possible way is to expose a
|
|
IMHO, definitely a library that is supposed to run in single thread mode (or that provides an option for it, such as |
|
Please note the |
:) |
…tp_init_nothreads()` ## Details - A port of PR sctplab#472 (that was never merged upstream project). - For experimentation purposes.
I believe it make sense not to stat
SCTP iteratorthread, when library was intentionally initialized viausrsctp_init_nothreads.In case user of library desire to disable threads there should no threads created.
I see main use cases of
usrsctp_init_nothreadsis to implement single threaded processing ofSCTPpackets for applications which need to implement WebRTC's data channel.It is occurred that completely single threaded processing is impossible due to
SCTP iteratoris still started when library initialized viausrsctp_init_nothreads.Moreover this thread is still doing some work - it is not always in dormant state.
So far I've figured out that some processing on
SCTP iteratoris triggered by timer, with example call stack:usrsctp/usrsctplib/netinet/sctputil.c
Lines 2171 to 2176 in 79ce3f1
usrsctp/usrsctplib/netinet/sctputil.c
Lines 1694 to 1746 in 79ce3f1
usrsctp/usrsctplib/netinet/sctp_pcb.c
Lines 8121 to 8207 in 79ce3f1
@tuexen do you think it is possible to accept this PR to make library behave as promised by name of
usrsctp_init_nothreads? Thanks a lot in advance!